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(54) Transaction data object features including persistence, passing object and using object data 
for printing 



(57) An automated banking machine (12) is opera- 
tive to conduct transactions in response to HTML doc- 
uments and TCP/IP messages exchanged with a local 
computer system (14) through an intranet (16), as well 
as in response to messages exchanged with foreign 
servers (20, 22, 24, 26, 28,) in a wide area network (18). 
The banking machine includes a computer having an 
HTML document handling portion. The HTML document 
handling portion is operative to communicate through a 
proxy server, with a home HTTP server in the intranet 
or the foreign servers in the wide area network. The 
computer further includes a device application portion 
which interfaces with the HTML document handling por- 
tion and dispatches messages to operate devices in the 
automated banking machine. The devices include a 



sheet dispenser mechanism which dispenses currency 
as well as other transaction devices. The device appli- 
cation portion communicates with a device interfacing 
software portion in the banking machine through a de- 
vice server in the intranet. The device server maintains 
local control over the devices in the banking machine 
including the sheet dispenser. The banking machine op- 
erates to read indicia on the user's card corresponding 
to a system address. The computer is operative to con- 
nect the banking machine to the home or foreign server 
corresponding to the system address, which connected 
server operates the banking machine until the comple- 
tion of transactions by the user. 
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Description 

[0001] This invention relates to automated banking 
machines. 

[0002] Automated banking machines are well known. 
A common type of automated banking machine used by 
consumers is an automated teller machine ("ATM"). 
ATMs enable customers to carry out banking transac- 
tions. Common banking transactions that may be car- 
ried out with ATMs include the dispensing of cash, the 
making of deposits, the transfer of funds between ac- 
counts, the payment of bills and account balance inquir- 
ies. The type of banking transactions a customer can 
carry out are determined by capabilities of the particular 
banking machine and the programming of the institution 
operating the machine. Other types of automated bank- 
ing machines may allow customers to charge against 
accounts or to transfer funds. Other types of automated 
banking machines may print or dispense items of value 
such as coupons, tickets, wagering slips, vouchers, 
checks, food stamps, money orders, scrip or travelers 
checks. For purposes of this disclosure an automated 
banking machine or automated transaction machine 
shall encompass any device which carries out transac- 
tions including transfers of value. 
[0003] Currently ATMs are operated in proprietary 
communications networks. These networks intercon- 
nect ATMs operated by financial institutions and other 
entities. The interconnection of the networks often ena- 
bles a user to use a banking machine operated by an- 
other institution if the foreign institution's banking ma- 
chine is interconnected with the network that includes 
the user's institution. However when the customer op- 
erates the foreign institution's machine the customer 
must operate the machine using the customer interface 
that has been established by the foreign institution for 
its banking machines. In addition the user is limited to 
the transaction options provided by the foreign institu- 
tion. 

[0004] A customer may encounter difficulties when 
using a foreign institution's machine. Problems may oc- 
cur because the user is not familiar with the type of ma- 
chine operated by the foreign institution. Confusion may 
result because the customer does not know which but- 
tons or other mechanisms to actuate to accomplish the 
desired transactions. The transaction flow for a custom- 
er at a foreign institution machine may be significantly 
different from machines operated by the user's home in- 
stitution. This may be particularly a problem when the 
user is from another country and is not familiar with the 
type of banking machine or the language of the interface 
provided by the foreign institution. Likewise, the docu- 
ments which are printed by printers in an automated 
banking machine are generally limited to a limited group 
of defined formats in a single language. 
[0005] A foreign institution may also provide different 
types of transactions than the user is familiar with at their 
home institution. For example the user's home institu- 



tion may enable the transfer of funds between accounts 
through their automated banking machines, to enable 
the user to maintain funds in higher interest bearing ac- 
counts until they are needed. If the foreign institution 
5 does not provide this capability, the user will be unable 
to do this when operating the foreign machine. The in- 
ability of a user at a foreign machine to conduct the 
transactions that they are accustomed to may present 
problems. 

io [0006] The networks that operate automated teller 
machines and other types of automated banking ma- 
chines generally operate proprietary networks to which 
access is restricted. This is necessary to prevent fraud 
or tampering with the network or user's accounts. Pro- 
's prietary networks are also generally used for the trans- 
mission of credit card messages and other financial 
transaction messages. Access to such credit card 
processing systems is also restricted primarily for pur- 
poses of maintaining security. 
so [0007] Communication over wide area networks ena- 
bles messages to be communicated between distant lo- 
cations. The best known wide area network is the Inter- 
net which can be used to provide communication be- 
tween computers throughout the world. The Internet is 
25 not widely used for financial transaction messages be- 
cause it is not a secure system. Messages intended for 
receipt at a particular computer address may be inter- 
cepted at other addresses without detection. Because 
the messages may be intercepted at locations that are 
so distant in the world from the intended recipient, there is 
potential for fraud and corruption 
[0008] Companies are beginning to provide ap- 
proaches for more secure transmission of messages on 
the internet. Encryption techniques are also being ap- 
35 plied to Internet messages. However the openness of 
the Internet has limited its usefulness for purposes of 
financial messages, particularly financial messages as- 
sociated with the operation of automated banking ma- 
chines. 

40 [0009] Messages in wide area networks may be com- 
municated using the Transmission Control Protocol/In- 
ternet protocol ("TCP/IP"). U.S. Patent No. 5,706,422 
shows an example of a system in which financial infor- 
mation stored in databases is accessed through a pri- 

■*5 vate wide area network using TCP/IP messages. The 
messages transmitted in such networks which use TCP/ 
IP may include "documents" (also called "pages"). Such 
documents are produced in Hypertext Markup Lan- 
guage ("HTML") which is a reference to a type of pro- 

50 gramming language used to produce documents with 
commands or 'tags" therein. The tags are codes which 
define features and/or operations of the document such 
as fonts, layout, imbedded graphics and hypertext links. 
HTML documents are processed or read through use of 

55 a computer program referred to as a "browser". The tags 
tell the browser how to process and control what is seen 
on a screen and/or is heard on speakers connected to 
the computer running the browser when the document 



3 



EP 0 964 374 A2 



4 



is processed. HTML documents may be transmitted 
over a network through the Hypertext Transfer Protocol 
("HTTP"). The term "Hypertext" is a reference to the abil- 
ity to embed links into the text of a document that allow 
communication to other documents which can be ac- 
cessed in the network. 

[0010] Thus there exists a need for an automated 
banking machine and system that can be used in a wide 
area network such as the Internet while providing a high 
level of security. 

[0011] Various aspects of the invention are exempli- 
fied by the attached claims and by the list of sequentially 
numbered clauses 1 to 220 found at the end of the de- 
scription. 

[001 2] It is therefore possible to provide: 

an automated banking machine and system which 
provides a user with the familiar interface and trans- 
action options of their home institution when oper- 
ating foreign institution machines: 

an automated banking machine which may provide 
more transaction options and types of promotional 
and printed materials to users: 

an automated banking machine at which a user may 
conduct transactions: 

an automated banking machine that may be oper- 
ated through connection to a wide area network: 

an automated banking machine that provides great- 
er options for machine outputs: 

an automated banking machine that communicates 
using HTML documents and TCP/IP messages: 

an automated banking machine that enables the 
connection of the banking machine to a user's home 
institution through HTML documents and TCP/IP 
messages generated responsive to indicia on a 
card input by a user: 

an automated banking machine and system that ac- 
complishes transactions over a wide area network 
while maintaining a high level of security: 

an automated banking machine and system that 
controls connection of the banking machine to for- 
eign addresses through a proxy server: 

an automated banking machine that limits the op- 
eration of devices in the machine through a local 
device server: 

an automated banking machine and system that is 
operable through connection to the Internet: 



an automated banking machine that may be used 
to provide a user with more types of messages in- 
cluding messages targeted to particular users: 

s an automated banking machine which is capable of 
providing users with a wider variety of printed doc- 
uments: 

an automated banking machine which provides ad- 
10 ditional options for identifying authorized users: 

an automated banking machine that can be used in 
connection with existing transaction systems while 
providing enhanced functionality: 

15 

an automated banking machine which provides en- 
hanced diagnostic and service capabilities: 

an automated banking machine which performs 
20 transactions at a rapid pace: 

improved systems in which automated banking ma- 
chines are used: and/or 

ss improved methods of operation for automated 
banking machines and systems. 

[0013] According to one embodiment of the invention 
there is provided an automated banking machine that 

30 includes an output device such as a display screen, and 
an input device such as a touch screen or a keyboard . 
The banking machine further includes devices such as 
a dispenser mechanism for sheets of currency, a printer 
mechanism, a card reader/writer, a depository mecha- 

35 nism and other physical transaction function devices 
that are used by the machine to accomplish banking 
transactions. 

[0014] The banking machine further includes a com- 
puter. The computer is in operative connection with the 

40 output devices and the input devices, as well as with the 
sheet dispenser mechanism, card reader and other 
physical transaction function devices in the banking ma- 
chine. The computer includes software programs that 
are executable therein. The software programs include 

■ts an HTML document handling portion. The HTML docu- 
ment handling portion operates to send and receive 
HTML documents and HTTP messages. The HTML 
document handling portion is preferably in connection 
with the output device to display screens including hy- 

so pertext link indicators. The HTML document handling 
portion is also preferably in connection with the input 
device which enables user selection and the generation 
of response messages from the computer. The HTML 
document handling portion preferably operates in con- 

ss nection with a JAVA software environment and has the 
capability of executing instructions in JAVA script trans- 
mitted with HTML documents. 

[0015] The software in the computer further prefera- 
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bly includes a device application portion. The device ap- 
plication portion includes software that is operative to 
control the sheet dispenser and other devices. In one 
embodiment of the invention the device application por- 
tion includes a plurality of JAVA applets for operating the 
devices in the machine. 

[0016] The computer in the automated banking ma- 
chine further includes a device interfacing software por- 
tion. The device interfacing software portion operates to 
receive messages from the device application portion 
and to cause the devices to operate through appropriate 
hardware interfaces. In one preferred form of the auto- 
mated banking machine, the HTML document handling 
portion, device application portion and device interfac- 
ing software portion each reside on the same computer 
and communicate at different IP ports. 
[0017] The automated banking machine in one con- 
figuration communicates using TCP/IP messages in an 
intranet which includes a plurality of such machines. The 
intranet is in turn connected to at least one computer 
which is operated by a home institution. The home in- 
stitution is the entity that operates the banking ma- 
chines. 

[0018] The computer of the home institution prefera- 
bly includes a home HTTP server, a proxy server and a 
device server. The proxy server communicates through 
the intranet with the HTML document handling portion 
of the software in each of the banking machines. The 
proxy server is also connectable to a wide area network, 
such as the Internet, to which foreign servers are con- 
nected. The device server is operative to pass messag- 
es between the device application portion and the de- 
vice interfacing software portion of the banking ma- 
chines. The device server may include monitor software 
which monitors and selectively limits the use and oper- 
ation of the devices in the banking machine. This pro- 
vides a level of security. 

[0019] The automated banking machine and system 
is operative to place a user in connection with the insti- 
tution where they have their accounts. This can he either 
the home institution that operates the banking machine 
where the user is present, or a foreign institution which 
is connected to the wide area network. To operate the 
banking machine a user provides inputs which corre- 
spond to an address, such as a URL address, through 
an address input device. The HTML document handling 
portion operates to connect the banking machine to the 
server corresponding to that address. This is preferably 
accomplished by the user having indicia representative 
of the address on a card that is read by a card reader in 
the banking machine, or other input device which iden- 
tifies the user or an institution or entity with which the 
user has accounts. 

[0020] The HTML document handling portion is re- 
sponsive to the address on the card or other input data 
to connect through the proxy server to the user's insti- 
tution. If the user's home institution address corre- 
sponds to the home server, the banking machine oper- 



ates responsive to messages from the home server. If 
however the user's input address corresponds to an ad- 
dress of a foreign server, the proxy server is operative 
to communicate through the wide area network with the 

s foreign server at the customer's home institution. If the 
customer causes the machine to connect a server op- 
erated by a foreign institution, the HTML documents 
sent from the foreign institution correspond to those nor- 
mally provided by the foreign institution. As a result the 

10 customer is familiar with the interface produced by these 
documents and will be able to more readily operate the 
banking machine. 

[0021] The foreign server or home server operate the 
banking machine by sending HTML documents that in- 

is elude instructions for operating the devices in the bank- 
ing machine. The instructions are transmitted from the 
HTML document handling portion to the device applica- 
tion portion of the software, which operates the devices 
in response to the instructions. The instructions from the 

20 device application portion to the devices in the automat- 
ed banking machine are passed through the device 
server of the home institution. This helps to maintain se- 
curity. In addition, the proxy server includes screening 
software which limits the foreign servers which may con- 

25 nect to and operate the banking machine. This is re- 
ferred to as a "fire wall." 

[0022] Some embodiments of the present invention 
also provide enhanced user interfaces and for the print- 
ing of a wide variety of documents with the banking ma- 
30 chine. Some embodiments enable achieving enhanced 
functionality while utilizing existing transaction networks 
and automated transaction machines. 

BRIEF DESCRIPTION OF DRAWINGS 

35 

[0023] Figure 1 is a schematic view of a network con- 
figuration including an automated banking machine ap- 
paratus and system, 

[0024] Figure 2 is a schematic view of one embodi- 

40 ment of an automated banking machine. 

[0025] Figure 3 through 24 show schematic views of 
the automated banking machine, an intranet connecting 
the banking machine to a computer system of a home 
bank and a wide area network connecting the computer 

-is system of the home bank to a foreign bank. 

[0026] Figures 3 through 18 schematically represent 
steps in a transaction carried out at the banking machine 
with the computer system of the home bank. 
[0027] Figures 19 through 24 schematically represent 

so steps in a transaction carried out at the banking machine 
with the computer system of the foreign bank. 
[0028] Figure 25 is a schematic view of a network con- 
figuration including an alternative embodiment of an au- 
tomated banking machine. 

55 [0029] Figure 26 is a schematic view of frames in the 
HTML document handling portion of the alternative em- 
bodiment of the automated banking machine shown in 
Figure 25. 
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[0030] Figure 27 is a schematic view of a customer 
interface of an automated banking machine and function 
keys and keypad keys included in the interface. 
[0031] Figures 28-30 schematically represent exem- 
plary steps in converting function key and keypad key 
inputs to keyboard stream and mouse stream inputs. 
[0032] Figure 31 schematically represents exemplary 
steps in printing documents with the automated banking 
machine. 

[0033] Referring now to the drawings and particularly 
to Figure 1 , there is shown therein a network configura- 
tion schematically indicated 10. which includes the au- 
tomated banking machine apparatus and system of one 
preferred embodiment of the present invention. Network 
10 includes a plurality of automated banking machines 
12 which in this embodiment of the invention are ATMs. 
ATMs 1 2 are connected to a computer system of a home 
bank schematically indicated 14. Home bank computer 
system 14 is the computer system that is operated by 
the bank or other institution which has primary respon- 
sibility for the ATMs 1 2. Home bank computer system 
14 is connected to the ATMs 12 through an intranet 16. 
Intranet 16 is preferably a local or proprietary network 
that provides communication between the computer 
system 1 4 and the banking machines 1 2 using messag- 
es in the transmission control protocol/internet protocol 
("TCP/IP") format. 

[0034] The messages that are communicated through 
the intranet 1 6 are preferably TCP/IP messages and hy- 
pertext mark up language ("HTML") documents. In one 
preferred embodiment of the invention the HTML docu- 
ments sent through intranet 16 include embedded ob- 
ject oriented programming instructions, preferably in the 
JAVA® format which has been developed by Sun Micro- 
systems. The messages sent through intranet 16 may 
be sent in an encrypted or unencrypted form depending 
on the nature of the system and the security needs of 
the home bank. 

[003S] It should be understood that embodiments of 
the invention may process other forms of documents 
which include tags or instructions therein. For example 
a form of "extended" HTML has recently been proposed 
which may be used in embodiments of the invention. For 
purposes of this document all such forms of languages 
and variants which include documents, which docu- 
ments include instructions therein shall be referred to as 
HTML documents. Likewise, while JAVA® is used in the 
described embodiment, other programming languages 
may be used. For example, Active-X™ developed by Mi- 
crosoft Corporation or other languages may be used in 
other embodiments. Further it should be understood 
that the instructions included in documents may be op- 
erative to cause a computer to access other documents, 
records or files at other addresses to obtain a program 
to carry out an operation. 

[0036] Home bank computer system 14 is also con- 
nectable as shown to a wide area network 18. In some 
embodiments of the invention the wide area network 18 



is the Internet. In other embodiments of the invention, 
other wide area networks may be used. The wide area 
network preferably communicates messages in TCP/IP 
between numerous computer systems connected to the 

5 wide area network. These foreign computer systems are 
schematically represented by servers 20, 22, 24, 26 and 
28. It should be understood that servers 20 through 28 
may be operated by or connected to other financial in- 
stitutions throughout the world. Servers 20 through 28 

w preferably operate by communicating HTML documents 
and other HTTP messages. 

[0037] Figure 2 shows a schematic view of the ATM 
1 2 used in connection with one preferred embodiment 
of the invention. ATM 12 includes a touch screen 30. 

15 Touch screen 30 includes a display screen which serves 
as an output device for communication with a user of 
the machine. Touch screen 30. because it is a touch 
screen, also serves as an input device for receiving input 
instructions from a user. Touch screen 30 is connected 

20 through an interface 32 to a computer 34 which is pref- 
erably housed within the machine. Alternative embodi- 
ments of the invention may include other output devices 
such as audio speakers. 

[0038] Computer 34 is also in connection with a plu- 

25 rality of transaction function devices 36 which are includ- 
ed in ATM 1 2. Devices 36 include for example, a card 
reader/writer mechanism 38 and a keyboard 40. Devic- 
es 36 further include a sheet dispenser mechanism 42 
which is operative to dispense sheets, which in some 

30 preferred forms of the invention are currency or bank 
notes, Devices 36 also include a depository 44 for ac- 
cepting deposits into a secure location in the machine. 
A receipt printer 46 for providing transaction receipts to 
customers is also included among devices 36. A journal 

35 printer 48 is also included among the devices for keep- 
ing a hard copy record of transaction information. In oth- 
er embodiments other or additional transaction function 
devices which carry out other transaction functions may 
be used. Other embodiments may include fewer trans- 

40 action function devices. It should be further understood 
that while the described embodiment of the invention is 
an automated banking machine, the same principles 
may be employed in many types of transaction ma- 
chines that do not necessarily carry out banking trans- 

45 actions. 

[0039] Each of the devices is operatively connected 
to an internal control bus 50 within the banking machine 
1 2. The control bus 50 outputs the internal messages to 
the particular devices. Each device has an appropriate 

50 hardware interface which enables the particular device 
to operate to carry out its respective function in response 
to the messages transmitted to it on control bus 50. Card 
reader/writer 38 has a hardware interface schematically 
shown as 52. Hardware interfaces 54, 56, 58, 60 and 

55 62 are respectively operative to connect keyboard 40, 
sheet dispenser mechanism 42, depository mechanism 
44, receipt printer mechanism 46 and journal printer 
mechanism 48 to the control bus 50. 
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[0040] Computer 34 has several software programs 
that are executable therein. In the preferred embodi- 
ment of the invention these software programs include 
a device interfacing software portion generally indicated 
64. Device interfacing software portion 64 preferably in- 
cludes a software device interface 66 that communi- 
cates electronic messages with the control bus 50. The 
device interface software portion 64 also preferably in- 
cludes a device manager 68. The device manager is 
preferably operative to manage the various devices 36 
and to control their various states so as to be assured 
that they properly operate in sequence. The device 
manager is also preferably operable to create device ob- 
jects in the software so as to enable operation of the 
devices by at least one object oriented program 70. De- 
vice interfacing software portion 64 also includes the ob- 
ject oriented program portion 70. which in one preferred 
embodiment is an application written in the JAVA lan- 
guage. Program 70 works in conjunction with the device 
manager to receive object oriented JAVA messages 
which cause the devices to operate, and to transmit de- 
vice operation messages indicative of a manner in which 
devices are operating and/or are receiving input data. 
[0041] The device interfacing software portion 64 in 
the described embodiment operates on computer 34 
and communicates through a physical TCP/IP connec- 
tion 72 with the intranet 16. The physical connection 
may be analog dial-up, serial port. ISDN connection or 
other suitable connection. In the configuration of the 
system as shown, device interfacing software portion 64 
communicates at the IP address of computer 34 and at 
an IP port or socket indicated 74 that is different from 
the other software applications. In other embodiments 
of the invention, device interfacing software portion 64 
may operate in a different computer than the other soft- 
ware applications of the invention. 
[0042] It should further be understood that although 
in the present embodiment of the invention the device 
interfacing portion 64 is software, in other embodiments 
of the invention all or portions of the instruction steps 
executed by software portion 64 may be resident in 
firmware or in other program media in connection with 
one or more computers, which are operative to commu- 
nicate with devices 36. For purposes of this document 
all such forms of executable instructions shall be re- 
ferred to as software. 

[0043] Other software also operates in computer 34. 
This software includes HTML document handling soft- 
ware which includes a browser, schematically indicated 
76. In the present embodiment of the invention the 
HTML document handling software includes a browser 
provided by Netscape®. However in other embodiments 
other HTML document handling and communicating 
software and browser software, such as Hot JAVA® by 
Sun Microsystems or Internet Explorer™ from Micro- 
soft, may be used. Browser 76 communicates in com- 
puter 34 at an IP port indicated by 78. 
[0044] Browser 76 is in operative connection with 



JAVA environment software 80 which enables computer 
34 to run JAVA language programs. JAVA language pro- 
grams have the advantage that they operate the same 
on a variety of hardware platforms without modification. 

s This "write once\run anywhere" capability makes the 
JAVA environment well-suited for the present embodi- 
ment of the invention. However other embodiments may 
use different types of software programs. 
[0045] The JAVA environment software 80 enables 

10 computer 34 to execute instructions in JAVA script, 
schematically indicated 82. The instructions that are ex- 
ecuted by the computer in JAVA script are preferably 
embedded JAVA script commands that are included in 
the HTML documents which are received through the 

is browser 76. The browser 76 in connection with the JAVA 
environment software 80 which executes instructions in 
the embedded JAVA script 82, serve as an HTML doc- 
ument handling software portion for transmitting and re- 
ceiving HTML documents and TCP/IP messages 

20 through the IP port indicated by 78. 

[0046] Computer 34 also has executable software 
therein having a device application portion 84. The de- 
vice application portion 84 contains executable instruc- 
tions related to operation of the devices 36. In the pre- 

2S ferred embodiment of the invention, the device applica- 
tion portion consists of a plurality of JAVA applets. In the 
described embodiment the applets are also preferably 
programs operable to control and keep track of the sta- 
tus of the devices with which they are associated. Cer- 

30 tain applets are also preferably operable toconfigure the 
browser to communicate messages. Certain applets 
manage security and authenticate entities that use the 
ATM. 

[0047] In the described embodiment of the invention. 

35 JAVA applets are associated with functions such as en- 
abling the card reader mechanism, notifying the browser 
when a user's card data has been entered, operating 
the receipt printer mechanism, operating the journal 
printer mechanism, enabling the customer keyboard 

40 and receiving data input through the keyboard, operat- 
ing the sheet dispenser mechanism, operating the de- 
pository, navigating to document addresses, timing de- 
vice functions, verifying digital signatures, handling en- 
cryption of messages, controlling the mix of bills dis- 

->s pensed from multiple sheet dispenser mechanisms, cal- 
culating foreign exchange, and ending a transaction and 
instructing the browser to return to communication with 
the home server. Of course, in other embodiments, oth- 
er applets may be used to control devices and use data 

50 to carry out various desired functions with the machine. 
The device application portion 84 communicates in the 
computer 34 at an IP port indicated 86. 
[0048] In the described embodiment of the invention, 
the device application portion 84 of the software does 

55 not communicate its messages directly to the device in- 
terfacing software portion 64. As later explained, this 
provides heightened security. However it should be un- 
derstood that embodiments of the invention may provide 
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for the device application portion 84 to directly commu- 
nicate device operation messages to the device pro- 
gram 70. This may be done either internally using TCP/ 
IP. by delivery of messages in a conventional manner 
through a queue established in the operating system of 
the computer that is associated with the software that 
interfaces with the devices, or by direct call to this soft- 
ware. 

[0049] From the foregoing discussion it will also be 
appreciated that certain applets in the device application 
portion 84 may correspond to devices which are not 
present in all automated teller machines. For example 
an automated teller machine that operates only as a 
cash dispenser does not include a depository mecha- 
nism like depository 44. To accommodate the situation 
where a user requests a transaction that is not physically 
possible with the ATM 1 2. the device interfacing soft- 
ware portion 64 may be programmed to provide an ap- 
propriate response message to indicate that the function 
is not available. 

[0050] Alternatively, the device interfacing software 
portion may include a function which checks for the 
presence or absence of each type of physical device 
within the ATM. Information indicative of the devices 
present in the ATM may be included as part of the mes- 
sages generated by the ATM. For example, information 
indicative of the devices which are operative in the ATM 
may be included as a portion or several parts of the U RL 
addresses to which messages are directed by the ATM. 
In this way, the URL in the server to which the ATM con- 
nects may be configured for providing only HTML doc- 
uments which correspond to the types of transactions 
that the ATM is capable of performing. As a result the 
browser avoids displaying documents which include ref- 
erences to transaction types that the machine is not ca- 
pable of performing. Thus for example, a machine may 
avoid producing a display in response to a document 
which includes a reference to a deposit transaction if the 
machine does not include a depository. 
[0051] Alternatively the machine may include in mem- 
ory, data representative of the functional devices includ- 
ed in the machine. This may include for example data 
representative of a plurality of devices in the machine 
and the configurations of such devices, or alternatively, 
a designator such as a machine number sufficient to 
identify the capabilities of the machine. The device data 
indicative of the functional devices in the machine is 
communicated to a server and the server is operative to 
deliver the appropriate HTML documents for the devices 
present in the machine. This may be done based on the 
data corresponding to the device data from the machine 
or may be resolved from a memory which holds data 
representative of the functional devices in a machine as- 
sociated with a particular designator. Documents selec- 
tively delivered by the server to the browser of the ma- 
chine will include the appropriate references to the func- 
tional devices present in the machine. These docu- 
ments may be static documents or may be generated at 



run time from subdocuments or otherwise, to provide the 
appropriate outputs and instructions to the output devic- 
es of the transaction machine. 
[0052] Figure 3 shows the ATM 1 2 in communication 

5 through the intranet 16 with the home bank computer 
system 1 4. Computer system 1 4 includes a proxy server 
88. System 1 4 further includes a home HTTP server 90. 
Computer system 14 further includes a device server 
92. The proxy server, home HTTP server and device 

jo server may be included in a single computer as shown, 
or in other embodiments may be separate computers. 
Additional servers may be operative in other embodi- 
ments. 

[0053] The home HTTP server 90 is preferably in 

is communication with a data store and is in electronic 
communication with a back office computer system, 
schematically indicated 94. Back office computer sys- 
tem 94 is operative to keep track of debiting or crediting 
customers' accounts when they conduct transactions at 

20 the automated banking machines. In addition back of- 
fice 94 is also preferably operative to track transactions 
for purposes of accomplishing settlements with other in- 
stitutions who are participants in the system and whose 
customers conduct transactions at the ATMs 12. 

25 [0054] As later explained, proxy server 88 is also op- 
erative in the described embodiment to communicate 
through the wide area network 18 with foreign servers 
such as foreign server 96. Foreign server 96 is an ex- 
ample of a server operated by an institution or entity oth- 

30 er than the institution which operates computer system 
1 4. It should be understood that while foreign server 96 
is indicated as operated by a "foreign" institution, this is 
not necessarily indicative that the institution is located 
in another country from the institution that operates 

35 computer system 1 4. However, it is possible that foreign 
server 96 could be located in such a foreign country, in- 
cluding a country in which the language spoken is dif- 
ferent from that generally used in the country where 
ATM 1 2 is located. 

jo [0055] The conduct of transactions using the ATM 1 2 
is now explained with reference to Figures 3-24. It 
should be understood that the following described trans- 
action flows are merely examples of the operation of the 
apparatus and system, and the apparatus and system 
45 may be configured and operated in numerous ways to 
carry out transactions. 

[0056] At the start of an exemplary transaction, as 
schematically represented in Figure 3, the browser 76 
communicates through the intranet 16 with the proxy 

so server 88. The communication is established preferably 
in a manner so that HTML documents intended to attract 
customers to the ATM 12 are displayed on the touch 
screen 30. This is referred to as the "attract mode." 
These HTML documents which are processed in the 

55 browser to produce the outputs in the form of screens 
on the touch screen 30 (and/or outputs through other 
output devices included in the machine) may originate 
from home HTTP server 90 which is operative to deliver 
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the HTML documents to the proxy server. The home HT- 
TP server sends the messages addressed to the IP port 
associated with browser 76, so as to cause their display 
at the proper ATM machine. It should be understood that 
while in this example, home server 90 is described as 
communicating with the ATMs through the proxy server 
88, the server 90 may in other systems encompassed 
by the invention communicate directly with the ATMs. 
[0057] A fundamental advantage of the system is that 
home HTTP server 90 may deliver documents selective- 
ly to the ATMs 12 connected to the intranet 16. These 
documents may include messages or material tailored 
to the particular location in which an ATM 12 is located. 
Examples of particularly tailored screens may include 
bilingual messages in certain neighborhoods or infor- 
mation concerning currency exchange at various ports 
of entry. The material or messages could include adver- 
tising for various products or services or other material 
targeted to particular machine locations. The JAVA ap- 
plets and JAVA script are loaded from a central location 
providing selective software distribution in the ATMs 
which may also be used to tailor the ATM do its environ- 
ment by causing it to access documents which include 
material intended to be useful in that location, and which 
is not provided in documents delivered to at least some 
other machines in the system. 

[0058] Systems of embodiment of the invention may 
be configured to have selected machines access HTML 
documents at different addresses, so that the particular 
documents accessed include the material targeted to 
users of the particular machine. Alternatively, a machine 
may communicate machine data indicative of its identity 
■ and/or location to a server. From the machine data, and 
data stored in a data store in connection with the server, 
the server operates to deliver the documents including 
the targeted material. This may be accomplished by as- 
sembling subdocuments, or otherwise, to generate the 
documents that will be delivered to the browser of the 
particular machine. In addition it should be understood 
that while in the embodiment shown the HTML docu- 
ments are accessed through a server of an institution 
associated with the machine, the documents used for 
the attract mode may be accessed from other servers 
operated by other entities. 

[0059] The touch screen 30 in this exemplary trans- 
action sequence displays a screen which includes an 
icon which indicates in one or more languages that to 
commence a transaction a user should touch the 
screen. If a user touches the screen in the area of the 
icon an input signal is generated. The input signal or 
HTTP message is transmitted through the browser 76 
to the home address of the home HTTP server 90 to 
which the ATM 12 is currently in communication. The 
message generated back to the home HTTP server is 
represented by the arrows directed from the browser 76 
to the intranet 1 6, from the intranet 1 6 to the proxy server 
88, and from the proxy server to the HTTP server 90 in 
Figure 3. 



[0060] In response to the home HTTP server 90 re- 
ceiving the message indicating that a customer has 
touched the icon on the screen, the home server is op- 
erative responsive to the address accessed to send a 

s message through the proxy server 88 (or in other em- 
bodiments directly) to the browser 76. This message 
preferably includes an HTML document which when 
processed through the browser produces a screen in- 
structing the customer to insert their card into the card 

10 reader mechanism 38. The HTML document flow which 
is represented graphically in Figure 4. preferably also 
includes embedded JAVA script or other instructions 
which operate in the JAVA environment to communicate 
a message to the JAVA applet responsible for enabling 

15 the card reader in the device application portion 84. In 
one preferred embodiment the instructions provide a 
pointer or tag to the applet which executes responsive 
to receipt of the document instructions. Of course in oth- 
er embodiments other software and approaches may be 

20 used. 

[0061] As shown in Figure 5. in response to the em- 
bedded JAVA script activating the JAVA applet associ- 
ated with the enable card reader function, the JAVA ap- 
plet in the device application portion 84 communicates 

25 with the device server 92. The device server 92 includes 
a device server program 98 which in the preferred em- 
bodiment is a JAVA program that enables communica- 
tion with the JAVA applets and the device server appli- 
cation 100. The device server 92 further preferably in- 

30 eludes a monitor software application 102 which is op- 
erative to monitor device operation instructions. The 
monitor software minimizes the risk of fraud or abuse in 
a manner later explained. 

[0062] Returning to the sample transaction, in re- 
35 sponse to receiving the enable card reader message 
from the device application portion 84. the device server 
92 is operative to generate a message through the in- 
tranet 1 6 to the device interfacing software portion 64 of 
the ATM 12. This message which comprises an HTTP 
40 record including instructions for operating the card read- 
er, is directed to the IP port indicated 74 which is where 
the device interfacing software portion 64 communi- 
cates. In response to receiving this message, the soft- 
ware portion 64 is operative to send a message or mes- 
45 sages on the control bus 50 which enables card reader 
mechanism 34. 

[0063] Continuing with the transaction as shown in 
Figure 6, the input of the card by the customer to the 
card reader 34 is operative to cause the card data to be 

so read and the device interfacing program portion 64 to 
send a message to the device server 92 indicating the 
card data has been read. This message is transmitted 
by the device server through the intranet 16 to the device 
application portion 84. The device application portion 

ss then sends a message to the device server requesting 
the card data. The device server 92 transmits a mes- 
sage with instructions to deliver the card data from the 
device interfacing software portion 64 which responds 
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with a message sending the card data through the in- 
tranet to the device server. The device server if there is 
no basis for stopping the transaction, transmits an HTTP 
record including card data back through the intranet 16 
to the device application portion 84. 
[0064] In one preferred embodiment of the invention, 
the card input by a user or customer includes indicia 
which corresponds to an address associated with the 
user in the network. In such an embodiment the indicia 
corresponds to a uniform resource locator ("URL") ad- 
dress which provides information on the computer 
where the user information resides, as well as a direc- 
tory or subdirectory which includes the user information 
and the name of the document or resource that includes 
the user information. The URL address may be encoded 
on a customer's card. The address may be encoded on 
track 3 of a magnetic stripe, in other locations within the 
magnetic stripe data or through encoding other readable 
indicia on the card. Alternatively, if the customer's card 
is a "smart" card which includes semiconductor storage 
thereon, the URL address associated with the customer 
may be included as part of the stored data on the inte- 
grated circuit chip on the customer's card. Alternatively, 
a URL could be derived from other data on the card by 
accessing a data base in which address data is corre- 
lated with other data read from the card. The data nec- 
essary to derive the address for accessing documents 
associated with a customer could also be derived from 
inputs to input devices other than or in addition to card 
data, including for example biometric data which is input 
by a customer through a biometric reading device. Such 
biometric data may include for example, data corre- 
sponding to one or more fingerprints, data from the us- 
er's appearance or combinations thereof. 
[0065] For example and without limitation, data input 
by a customer such as through a card input to a card 
reader may correspond to an address for accessing an 
HTTP record, which may be a file or document which 
includes information which can be used for verifying the 
identity of a user. This record could include data corre- 
sponding to a PIN number. The information may include 
biometric data corresponding to the authorized user of 
the card. The browser may access the record and use 
the contents of the record such as data and/or instruc- 
tions to verify that the indicia corresponding to biometric 
data in the record corresponds to the biometric data of 
the user entering the card. Alternatively, input data rep- 
resentative of appearance, voice, other features (or 
combinations thereof) or other input data, may be used 
to generate one or more addresses which correspond 
to a user, and the content of the record at the accessed 
address used to verify that the user at the machine cor- 
responds to the user associated with the record. Numer- 
ous approaches within the scope of the invention may 
be used. The information in the record corresponding to 
a user may likewise be used to authorize certain func- 
tional devices on the machine to operate for the user 
while other devices may not. For example, a user who 



is overdrawn may have information in the record ac- 
cessed that prevents them from actuating the cash dis- 
penser, while users who are not overdrawn may include 
information which enables such operation. Alternatively, 
5 the absence of information in a corresponding record 
may enable operation, while the inclusion of information 
selectively limits the operation of devices. 
[0066] Returning to the exemplary transaction, the 
delivery of the card data from a successfully read card 
10 is delivered responsive to the programming of the de- 
vice application portion 84 to a JAVA applet associated 
with notifying that the card data has been entered. In 
response, the JAVA applet operates to generate JAVA 
script which configures the browser with the URL ad- 
is dress corresponding to the data read from the card. The 
JAVA applet is also preferably operative to open a record 
schematically indicated 1 04 concerning the transaction, 
which includes the user's URL address, the time and 
other card data. This record in a preferred embodiment 
20 may be stored in memory as data in an object in soft- 
ware. The object is preferably used to accumulate data 
as the transaction proceeds. The data stored in the 
transaction data object preferably includes data input 
through input devices by the user as well as data repre- 
ss sentative of operations carried out by transaction func- 
tion devices. 

[0067] The record or transaction data object provides 
persistence through what may be several different 
transaction steps executed by the customer. The ability 
30 to use and share the data in a number of different oper- 
ations avoids the need to derive it or obtain it from a 
customer more than once in the course of a user session 
involving a number of transaction steps. The use of a 
transaction data object enables applets to run largely 
35 independently, obtaining needed data from the transac- 
tion object. The approach also enables the record or da- 
ta object to be used to produce an appropriate record at 
the end of the transaction session. This record may be 
stored, collected into a batch or delivered to selected 
40 addresses in a local or wide area network. 

[0068] As schematically shown in Figure 7, in re- 
sponse to the browser 76 receiving the URL address 
data, the browser is operative to transmit a message 
through the intranet 16 to the proxy server 88. For pur- 
45 poses of this example, the URL address associated with 
the card data is that of a customer associated with the 
home bank which operates system 14. As a result, the 
customer's URL address will cause the message to be 
directed from the proxy server 88 to the home HTTP 
so server 90 and to access the corresponding document at 
the address therein. Alternatively, in other systems the 
connection may be made directly with server 90 without 
the intervening proxy server 88. As previously dis- 
cussed, the URL address may also include data repre- 
ss sentative of the devices which are operative in the ATM. 
[0069] In response to receiving the message, home 
HTTP server 90 finds the data corresponding to the cus- 
tomer's URL address data in its associated memory and 
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delivers to the browser at its IP port with an HTML doc- 
ument. This HTML document may include a screen ac- 
knowledging the particular customer by name as well as 
with the name of the banking institution or other entity 
which operates the home bank computer system 14. 
[0070] In addition, the HTML document preferably in- 
cludes embedded JAVA script which has a digital signa- 
ture or a means to obtain a digital signature associated 
with the home HTTP server 90. The script instruction 
included in the document in certain embodiments caus- 
es the device application portion to access an HTTP ad- 
dress on a server, which in the described embodiment 
is server 90. The HTTP address corresponds to an HT- 
TP record which includes at least one instruction and 
preferably includes a program such as a JAVA applet or 
Active-X file. The instruction is used to operate the ap- 
propriate transaction function device. The HTTP record 
preferably includes data representative of a signature, 
such as a digital signature. This digital signature is re- 
ceived responsive to the JAVA script 82 and processed 
in the device application portion 84. A JAVA applet proc- 
esses the digital signature to authenticate it and if it is 
an acceptable signature authorizes operation of the 
banking machine. In certain embodiments the applet 
may compare the signature to signature data stored in 
memory for a predetermined relationship, such as a 
match. 

[0071 ] After the applet verifies that HTTP server 90 or 
other accessed HTTP record has sent a proper digital 
signature, the transaction will be allowed to continue. If 
for some reason a proper digital signature has not been 
sent, the JAVA applet will stop the transaction and return 
banking machine 12 back to the condition prior to the 
start of the transaction by connecting the ATM to the ad- 
dress associated with the attract mode in home server 
90. The use of signed instructions may be used to as- 
sure that the various transaction function devices are 
only operated in response to appropriate messages. 
The use of signed instructions may be particularly ap- 
propriate for instructions that run the sheet dispenser or 
otherwise provide value to the user of the machine. 
[0072] In the example it will be assumed that the dig- 
ital signature received is a proper signature, in which 
case a message is returned from the browser 76 to 
home server 90 indicating that the transaction may pro- 
ceed. As shown in Figure 8, in this exemplary transac- 
tion the HTTP home server 90 then operates to send an 
HTML document to the browser 76 which includes in- 
structions which when processed produce a page or 
screen which instructs the customer to enter their per- 
sonal identification number or PIN. This HTML docu- 
ment preferably includes embedded JAVA instructions 
which operate to cause the device application portion 
84 enable the keyboard 40 of the ATM so the machine 
may receive the PIN number. Such a message is sche- 
matically shown in Figure 8 with the JAVA script 82 sig- 
naling the JAVA applet responsible for the keyboard that 
it has been requested to enable the keyboard. In re- 



sponse the JAVA applet in the device application portion 
84 sends a message through the intranet 16 to the de- 
vice server 92. The device server 92 sends a message 
back through the intranet to the device interfacing soft- 

s ware portion 64 in the ATM. The instructions in this mes- 
sage causes the device software to enable keyboard 40. 
The JAVA applet responsible for enabling the keyboard 
is also preferably operative to update the transaction 
record 104 to indicate that the PIN was requested. 

10 [0073] As shown in Figure 9. the PIN entered through 
the keyboard 40 is transmitted in a message from the 
device interfacing software portion 64 to the device serv- 
er 92. The device server 92 returns a message to the 
responsible JAVA applet in the device application por- 

15 tion. The JAVA applet then operates to send a message 
back through the HTML document handling portion and 
the browser 76 to the HTTP address of home server 90. 
This message includes data representative of the PIN 
input by the customer. In some embodiments it is not 

20 desirable to display the customer's PIN on the screen. 
In such embodiments the keyboard applet may be op- 
erative to display a default character on the screen such 
as a "*" symbol or other symbol in lieu of the PIN digits. 
Further as later discussed it may be desirable to avoid 

25 transmission of PIN or other data through the browser, 
in which case PIN data may be handled as a separate 
HTTP message or in other manner to reduce the risk of 
disclosure. 

[0074] The software operating in connection with HT- 

so TP server 90 is then operative to either verify the PIN 
itself or to verify the customer's PIN number and account 
number by sending it to the back office 94 and waiting 
for a response. Alternatively, customer PIN verification 
may be carried out in the ATM through an appropriate 

35 applet. This can be done in situations where data on a 
customer's card, such as an account number, can be 
correlated to the customer's PIN number through an al- 
gorithm. The embedded JAVA script in the HTML mes- 
sages may include or point to an address to obtain the 

■io data and/or instructions which the applet uses to per- 
form this verification function, including certain encryp- 
tion key data. This may include user information in the 
HTML document or other record data that was accessed 
in response to the user's card data. As shown schemat- 

■is jcally in Figure 9, the transaction data object 1 04 is also 
appropriately updated by the applet to indicate the entry 
of the customer's PIN. 

[0075] In alternative embodiments the machine may 
include a biometric reader device or other input device 

so to accept data from a user. The user may input data 
through such a device which may be used in lieu of, or 
in addition to, PIN data to verify that the user is an au- 
thorized user. This may be done for example by com- 
paring the user data input to information corresponding 

55 to the authorized user of the card included in a record 
or a document which has an HTTP address and is ac- 
cessed by a browser or by an HTTP client application 
through an HTTP server in response to card data. Alter- 
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natively input data may be used to generate addresses 
(or documents or records which are accessed by the 
browser or client, and which records or documents con- 
tain information that is used to verify the user's identity. 
For example, data concerning users may be stored in a 
data store in connection with an HTTP server, which de- 
livers data from a record responsive to the user data, 
which is used to verify the user's identity. 
[0076] It should be noted that the page or screen 
which requests the customer to enter their PIN is shown 
generated from the home HTTP server 90. This is pref- 
erably a screen that is associated with the particular cus- 
tomer's URL address. This will be the interface of the 
customer's home bank and will be familiar to the cus- 
tomer. Alternatively, the customer address may access 
what may be essentially the customer's personal "home 
page" with the institution that operates computer system 
14. As such, it is not only something the user is familiar 
with, but is ideally tailored to the user's particular trans- 
action needs. 

[0077] Alternatively, the document(s) or record(s) 
which contain the customer data may be used to gen- 
erate the addresses for other documents. The informa- 
tion may also be used to generate a document for the 
particular customer in the particular circumstances. This 
approach may be useful to reduce the effort associated 
with developing in advance a personal visual page or 
document for each customer. 
[0078] Approaches for accomplishing this may in- 
volve including various types or categories of user infor- 
mation in the document(s) or record(s) that pertain to a 
particular customer. This may include information such 
as gender, related persons, account types, permitted 
transactions, customer preferences, customer inter- 
ests, account balances, previous offers declined or ac- 
cepted and other information. This customer information 
can be used by an appropriate applet among applets 86 
to address and/or develop an appropriate document for 
the browser to access based on the customer "profile". 
In addition, the profile applet may take into consideration 
the transaction devices present in the particular ma- 
chine, information on which is stored in a data store in 
the machine or elsewhere in the system, as well as other 
factors such as the day of the week and time of day 
based on a system clock. In this way the machine de- 
termines the appropriate document to access or gener- 
ate for the particular customer under the particular cir- 
cumstances. 

[0079] The logic used in the profile applet may act to 
cause documents to be built or accessed for the cus- 
tomer which includes transaction options based on the 
customer information, information about the terminal 
and other factors. The profile applet may operate to offer 
transaction options or information selectively based on 
the customer information. For example, the operator of 
the machine may offer incentives, premiums, additional 
transaction options or advertising information selective- 
ly to customers. Certain types of customers of the insti- 



tution operating the machine may receive screen out- 
puts with options that encourage them to do more busi- 
ness or different types of business with the institution. 
Likewise, customers that are identified as customers of 

s foreign institutions may be provided with incentives to 
do business with the institution operating the machine. 
[0080] The profile applet may operate to cause the 
computer to access other documents in other servers, 
such as stock market data, and selectively provide it to 

to customers. It should be understood that the profile ap- 
plet may operate to determine an address or generate 
documents to produce initial display screens of a trans- 
action sequence. The profile applet may also operate to 
provide information or access or produce documents to 

15 generate visual outputs to the customer at other points 
in a transaction or between transactions. This may fur- 
ther be used in systems in which the operator of the ma- 
chine is able to sell paid advertising to third parties and 
then access the HTTP records such as HTML files for 

20 those third parties' products or services. Such access- 
ing may be done based on a periodic or other basis, but 
may be done effectively by selecting the HTTP record 
to access in response to the profile of the particular cus- 
tomer. 

25 [0081] The continuation of the transaction flow for this 
exemplary transaction by a customer of the institution 
that operates computer network 14. is schematically 
shown in Figure 10. The home HTTP server 90 is oper- 
ative in response to the customer inputting the correct 

30 PIN to send HTML documents to the HTML document 
handling portion of the software in the computer which 
operates the ATM. These messages may include infor- 
mation used to generate screens which prompt the cus- 
tomer to select a transaction. For purposes of this ex- 

35 ample, it will be assumed that the customer inputs at the 
touch screen 30 a selection which corresponds to the 
dispense of cash, which is a common transaction at an 
automated banking machine. 

[0082] The selection of the customer through the input 

40 device of the touch screen is communicated back 
through the HTML document handling portion which 
communicates an HTTP message to the home HTTP 
server 90. Server 90 then responds by sending another 
HTML document to the banking machine which prompts 

■is the customer to select an amount. Again the customer 
may input a selection on the touch screen which indi- 
cates the amount of cash requested by the customer. 
This HTTP message passes through the HTML docu- 
ment handling portion and the browser 76 to the home 

so server 90. 

[0083] In response to the receipt of amount data from 
the customer, the home server 90 is preferably operative 
to communicate electronically with the back office 94 to 
verify that the customer has the amount requested in 

55 their account. 'This is preferably accomplished through 
a Common Gateway Interface (CGI) 106 which is in op- 
erative connection with the home server 90. For purpos- 
es of this transaction it will be assumed that the back 
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office 94 indicates that the money is available in the cus- 
tomer's account and sends a message through the CGI 
1 06 to the home server 90 indicating that it may proceed. 
[0084] As schematically represented in Figure 11 , the 
home server 90 then operates to send a document back 
to the HTML document handling portion in the ATM soft- 
ware. This message preferably will cause information to 
be displayed on the screen which advises the customer 
that the transaction is being processed. In addition the 
HTML document returned preferably includes JAVA 
script which include embedded instructions which are 
executed and communicated to a JAVA applet associ- 
ated with the operation of the sheet dispensing mecha- 
nism 42. 

[0085] The document returned from the home server 
90 may include advertising or other information instead 
of or in addition to the customer message. The docu- 
ment returned may also include an instruction which 
causes the machine to access or generate another doc- 
ument. These instructions may invoke methods in the 
profile applet which depend on the properties associat- 
ed with the customer, the machine, the current time and/ 
or other circumstances. This enables accessing docu- 
ments that provide promotional messages such as ad- 
vertising or other information to the customer while the 
customer is waiting for the machine to operate It should 
be understood that these documents may be accessed 
anywhere, including from the Internet. This makes it 
possible to selectively present a wide range of materials 
to customers. It also enables operators of ATMs and oth- 
er transaction machines to present advertising to cus- 
tomers, on a broad basis, or targeted to categories of 
customers or even targeted to individual customers on 
a segment of one basis. This could be advertising of the 
machine operator such as a bank, or advertising per- 
taining to virtually any type of goods or services. The 
advertising may also be selectively presented based on 
the particular transaction device being operated, the 
amount of funds involved or other parameters. The 
HTML documents also enable the presentation of video 
and sound to the customer which may enhance the ef- 
fectiveness of promotions. 

[0086] The message to the JAVA applet in the device 
application portion 84 of the software to initiate opera- 
tion of the sheet dispenser results in generation of a 
message to the device server 92. The message to the 
device server 92 to dispense cash is preferably ana- 
lyzed by the monitor software 102 to check to see if the 
message is appropriate. For example the monitor soft- 
ware 102 is preferably operative to assure that the 
amount of cash being requested does not exceed a pre- 
set amount. It can also optionally check to verify that the 
amount provided to this customer within a prior period 
has not exceeded an amount. This may be done by the 
device server sending a message to the back office 
which includes the card data it has previously received 
from this customer. This message may pass through 
server 90 and its associated CGI, or other connection. 



Assuming that the dispense instruction is not prevented 
by a message from the back office or the monitor soft- 
ware, the device server 92 is operative to send a dis- 
pense message to the device interfacing software por- 

5 tion 64 in the ATM. The software portion 64 is thereafter 
operative responsive to the message to operate the 
sheet dispensing mechanism 42 to dispense the 
amount of cash requested by the customer. 
[0087] The monitor software 1 02 preferably performs 

to additional functions in the device server. For example, 
government regulations or good business practice may 
require limiting the size and amounts of deposits which 
may be made into an ATM. This may be advisable to 
prevent "money laundering" or other suspicious activi- 

75 ties. The monitor software preferably operates to limit 
the amount of any single deposit to below a set limit. It 
further operates by communicating with the home bank 
back office system 94 to prevent a series of deposits 
within a preset time from exceeding a certain limit. The 

20 monitor software may also work in connection with the 
proxy server to limit certain transactions that may be car- 
ried on at the banking machine responsive to instruc- 
tions from foreign servers as later discussed. 
[0088] It should be noted that in a preferred embodi- 
es ment of the invention the JAVA applet which is operative 
to send the message which causes cash to be dis- 
pensed, works in connection with another applet which 
controls the mix of bills dispensed to a customer. Many 
automated teller machines have the ability to dispense 

30 two or more denominations of currency bills. It is desir- 
able to control the mix of bills dispensed to a customer 
to suit that which is available in the machine and to avoid 
running out of one denomination of bills before the other. 
The bill mix applet is preferably operable to control the 

35 bill mix in accordance with the desires of the institution 
operating the ATM machine as well as is in accordance 
with the ATM machine's capabilities. Alternatively, a 
JAVA applet for controlling bill mix may reside in device 
program 70 in device interfacing software portion 64. 

40 [0089] As will be appreciated by those skilled in the 
art, the particular JAVA applets and/or configuration da- 
ta in the machine may be selectively loaded from the 
home server 90 at machine start up or at other times. 
Because the applets and configuration data may be se- 

-»s lectively delivered to particular machines, the machines 
may be tailored specifically to the particular ATMs cur- 
rency dispensing and other capabilities. For example, 
the ATM may be configured so that certain applets or 
groups of applets must be present to enable the ma- 

so chine to operate. One approach to loading such data or 
programs is to provide address values in the terminal 
software to indicate where the needed instructions to ac- 
quire the applets or data may be obtained. If the applets 
or groups of applets are not already present in memory 

55 of the ATM terminal at start up, the software is operative 
to access the system addresses for the documents 
which contain the required records or instructions which 
will cause the machine to load the required records. The 
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browser may be used to access the addresses and the 
software loads data corresponding to the instructions 
from the accessed documents into a memory in the ATM 
terminal so that the terminal has the required applets 
and data. Such document addresses may be accessible 
through the home server 90. Alternatively the addresses 
may be on a separate development server connected 
to the intranet 16. In this way each transaction machine 
is able to load the applets and data which include the 
operative code it needs to operate the transaction de- 
vices in the machine. Alternatively the documents may 
be provided through a development server or other serv- 
er that is accessible to the machine through a wide area 
network. The documents may be provided on the devel- 
opment server to provide the machine with instructions 
on how to acquire the operating code to carry out a wide 
variety of functions. The instructions may direct the ma- 
chine to acquire the necessary data and code from ad- 
dresses accessible through HTTP servers by an HTTP 
client in the machine. The data and code can be ac- 
quired responsive to instructions in one or several doc- 
uments. The machine may also require that the applets 
loaded in this manner be signed applets including digital 
signatures or other authenticating features to achieve 
operation of certain devices in the machines. 
[0090] Alternatively, embodiments of the invention 
may acquire the necessary applets and data from a re- 
mote data store. The data store preferably includes the 
data and/or programs that enable the machine to oper- 
ate as desired or have instructions on where the ma- 
chine may acquire the necessary instructions and data 
for operation. The data may be accessible from a data 
base server. The transaction machine addresses a que- 
ry to the database server. The query includes or is ac- 
companied by indicia from the machine which identifies 
the machine. This may be the particular machine such 
as a machine number, and/or may include indicia rep- 
resentative of the type or functional device capabilities 
of the machine. 

[0091] The data store preferably includes records 
which have the data or programs that are to be trans- 
mitted to the machine. In response to the query to the 
server, the server retrieves records from the data store 
and responsive thereto delivers one or more messages 
to the HTTP client in the transaction machine. This mes- 
saged) includes the configuration data or applets to en- 
able the machine to operate in the manner desired or 
may include instructions which indicate how the ma- 
chine is to acquire such programs from servers connect- 
ed in the system. 

[0092] In the example shown the configuration server 
and data store may operate on the same computer as 
home bank server 90. In other embodiments the data- 
base server may reside elsewhere in the networks to 
which the machine is connected. 
[0093] An advantage of the machines and systems 
which employ such features is the flexibility to change 
the operation and customer interface of the machine to 



respond to changing conditions. This may include a 
change in a transaction function device. Conditions may 
change so that certain transactions are limited or are not 
available. For example, a machine may normally accept 

s deposits but its depository is full. In that situation the 
machine may change the documents it accesses to 
present messages to users through its output devices 
so that the deposit option is no longer offered. This can 
be accomplished by the applets and data loaded into 

10 the machine initially, which provide for instructions when 
such event is sensed. Alternatively, the machine pro- 
gramming may be modified by loading new applets and/ 
or data from an HTTP server responsive to its then cur- 
rent status. This may be done responsive to a query to 

is a database server which includes or is accompanied by 
data representative of the changed conditions or capa- 
bilities of the machine. In response the server delivers 
the applet(s), data and/or instructions which will operate 
the machine in the modified mode. 

20 [0094] This approach eliminates the situation with 
conventional transaction machines where the static in- 
terface presentation on output devices offers a transac- 
tion option to a customer. Sometimes, after the custom- 
er has made the selection an indication is given that the 

25 selected transactions option is not available. The ap- 
proach described herein may be used with numerous 
transaction options and variations of transactions. The 
transaction options can be readily changed from the da- 
tabase server on a machine by machine basis or even 

30 a customer by customer basis as previously discussed, 
based on the desires of the entity operating the trans- 
action machine. 

[0095] The discussion of the exemplary transaction 
will now be continued. In response to the cash dispenser 

35 42 dispensing the requested amount of cash, device in- 
terfacing software program 64 preferably operates to 
send a dispense operation message confirming the dis- 
pense back to the JAVA applet responsible for the dis- 
pense in the device application program 84. As repre- 

40 sented in Figure 1 2. the particular applet is operative to 
update the transaction record 104 to indicate the dis- 
pense of currency to the customer in the particular 
amount. The embedded JAVA script instructions which 
were operative to cause the dispense of currency to the 

45 customer, also preferably include instructions to send a 
confirming message back to the home server 90 that the 
dispense is complete. The receipt of the dispense oper- 
ation message indicating the cash was dispensed caus- 
es the JAVA applet to configure the HTML document 

so handling portion to send a device response message 
back to the home server. The home server then is pref- 
erably operated in accordance with its programming to 
indicate to the back office 94 that the customer received 
the amount of funds dispensed. This amount is deduct- 

55 ed from the customer's account in the records main- 
tained by the back office system. 
[0096] Generally during a transaction it is common to 
ask the customer if they wish to have a receipt for the 
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transaction. This may be done at various times during 
the transaction flow. In the present example, after the 
cash has been dispensed the customer operating the 
machine is sent such a message as reflected in Figure 
1 3. The home server 90 is operative to send an HTML 
document which includes a screen asking the customer 
if they would like a receipt. This message is displayed 
as part of a page on the touch screen 30 responsive to 
receipt of the message through the browser 76. Alter- 
natively the document may be generated by the ma- 
chine. In response to the customer indicating that they 
do or do not want a receipt, a message is returned to 
the home server. Again it should be understood that the 
screens displayed to the customer are preferably those 
that the customer is accustomed to from his or her home 
institution, and may be a part of his or her unique home 
page. 

[0097] Assuming that the customer wishes to receive 
a transaction receipt, the home server 90 operates as 
shown in Figure 1 4 to send a document back to the ATM 
with embedded JAVA script indicating that a transaction 
receipt is to be printed. These instructions in JAVA script 
are communicated to the device application portion 84 
which sends a TCP/IP message through the intranet to 
the device server 92. The device server 92 in turn com- 
municates a message with instructions to the device in- 
terfacing software portion 64 in the ATM, In response to 
receiving the message, software portion 64 is operative 
to cause the printer 46 to print the customer's transac- 
tion receipt. The JAVA applet responsible for enabling 
the printer is also preferably operative to update the 
transaction data object or record 104. As later dis- 
cussed, the applet which controls the printing of the re- 
ceipt may obtain the data used in printing the receipt 
from the transaction data object. 
[0098] It should be understood that even if the cus- 
tomer does not wish to have a receipt it is desirable to 
print a record of the transaction in hard copy through the 
journal printer 48. This may be accomplished in re- 
sponse to imbedded instructions which are part of the 
same document from the home server 90 which causes 
the transaction receipt for the customer to be printed, or 
may be part of a separate document which indicates that 
the customer has declined the option to receive a trans- 
action receipt. Alternatively, the journal printer may be 
actuated responsive to other applets such as the applet 
which causes the dispense of cash, or in another man- 
ner chosen by the operator of the ATM. As will be ap- 
preciated from the foregoing description the operation 
of the present embodiment of the ATM is inherently flex- 
ible and programmable to meet the needs of the system 
operator. 

[0099] As shown in Figure 1 5 upon completion of the 
printing of the transaction receipt, the software portion 
64 is preferably operative to send a device operation 
message to the device server 92 which is indicative that 
the requested device function was carried out success- 
fully. The device server 92 is operative to send a corre- 



sponding device operation message to the device ap- 
plication portion 84, and in the preferred embodiment to 
the particular JAVA applet responsible for the printing of 
the receipt. The JAVA applet in turn configures the 
s HTML document handling portion to generate a mes- 
sage back to the home server in the form of a device 
response message to indicate that the receipt was print- 
ed for the customer. 

[0100] Having received cash and a receipt, the cus- 

10 tomer is then prompted by a display screen generated 
from an HTML document from the home server 90, to 
indicate whether they wish to conduct another transac- 
tion. The visual page or screen prompting the customer 
in this regard is displayed on the touch screen 30. For 

is purposes of this example it will be assumed that the cus- 
tomer does not want another transaction and a message 
to that effect is returned through the HTML document 
handling portion back to the home server 90. 
[0101] As shown schematically in Figure 17 in re- 

20 sponse to receiving a message that the customer is 
done, the home server 90 is operative to send a "go 
home" message to the ATM. This message preferably 
includes an HTML document which produces a screen 
display thanking the customer. This message also pref- 

25 erably includes embedded JAVA script which calls the 
JAVA applet which eventually returns the HTML docu- 
ment handling portion of the ATM back into connection 
with the URL address on the home server 90 or other 
address which provides the documents that are used to 

30 output the messages for the so called "attract mode". It 
should be remembered that the script in some embodi- 
ments may operate to cause a message to be sent from 
the document handling portion to an address on the 
home server witch causes a corresponding HTTP 

35 record including the instructions comprising the desired 
applet to load. 

[0102] As schematically indicated in Figure 18. the 
"go home" command applet is operative to configure the 
browser 76. After the HTML document handling portion 
40 is configured by the JAVA applet to return home, the 
JAVA applet may be configured to deliver to home server 
90 information from the transaction record 1 04 concern- 
ing the transaction that was just completed. Because the 
exemplary transaction was with a customer of the insti- 
ls tution that operates the computer system 1 4, all the data 
concerning that transaction should already be recorded 
in the back office 94. However it will be appreciated that 
this will not be the case if the transaction was conducted 
in response to messages from a server operated by a 
50 different institution. Thus, all or a portion of the informa- 
tion from the transaction record 104 may be delivered 
in response to a "go home" command to the home serv- 
er 90 and through the CGI to the back office system 94 
where it can be identified as duplicate information and 
55 discarded. This may be done using remote method in- 
vocation (RMI) to pass or deliver the object to server 90 
and then transmitting the data through messages from 
the server to the back office or through messages or oth- 
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er techniques. 

[01 03] Of course in other embodiments transaction in- 
formation may be stored in a database for extended pe- 
riods rather than being returned after each transaction. 
Alternatively the ATM 1 2 may include applets which are 
operable to deliver transaction record information to ad- 
dresses other than that of the home server, if that is de- 
sired by the operator of system 14. 
[0104] The operation of the computer system when a 
"foreign" user uses the ATM 12 is graphically represent- 
ed with regard to Figures 19 through 24. A transaction 
with a foreign user who is not a customer of the institu- 
tion that operates ATM 12 and computer system 14, will 
be operated under the control of the home server 90 and 
will proceed in the manner of the prior example through 
the point where the customer inputs their card. The cus- 
tomer inputs a card having indicia corresponding to a 
URL address that does not correspond to the home 
server 90. The HTML document handling portion is op- 
erative to configure a message addressed to access a 
URL address that corresponds to the indicia on the cus- 
tomer's card or other address responsive to such indi- 
cia. This message is delivered to the proxy server 88 
which in turn passes the message to the wide area net- 
work 1 8. From the wide area network the message pro- 
ceeds to the foreign server corresponding to the cus- 
tomer's URL address. For purposes of this example the 
foreign server corresponds to server 96 which is con- 
nected to the Internet. 

[0105] In the preferred embodiment of the invention 
proxy server 88 includes screening software graphically 
indicated 107. Screening software is preferably opera- 
ble to check addresses to which messages are being 
directed by the ATM and to selectively prevent the send- 
ing of messages to particular addresses. This serves as 
a "fire wall" and is desirable for purposes of preventing 
fraud in the system. 

[0106] As shown in Figure 20. the foreign server 96 is 
preferably operable to communicate HTTP messages, 
including HTML documents, to the ATM 1 2 back through 
the wide area network 18. This may be done using a 
secure socket connection ("SSC") so as to minimize the 
risk of interception of the messages. Of course other 
techniques, including encryption message techniques 
may be used to minimize the risk of interception of the 
messages. 

[0107] As schematically represented in Figure 20 the 
response document from foreign server 96 preferably 
includes embedded JAVA script is representative of or 
corresponds to a digital signature which identifies the 
foreign server 96. This may be accomplished by loading 
an HTTP record including a signed applet, as previously 
discussed. An applet in application portion 84 in the ATM 
preferably operates to verify the digital signature in the 
manner described in the prior example, and sends a 
message indicating that the transaction has been au- 
thorized. The digital identity of the foreign institution will 
be stored in memory in the ATM and eventually recorded 



in the back office 94. 

[0108] It should be noted that the HTML documents 
from the foreign server 96 produce the visual pages or 
screens of the foreign institution which the foreign cus- 

s tomer is accustomed to seeing. These pages may cor- 
respond to the foreign user's "home page" which are tai- 
lored specifically to the needs of the particular user. 
[0109] Figure 21 shows an example of a document 
accessed through the foreign server 96 to the ATM 1 2. 

10 The document from the foreign server may include em- 
bedded JAVA script which enables operation of the 
JAVA applets in the manner previously discussed to op- 
erate the devices 36 in the ATM. As shown in Figure 21 
the TCP/IP messages to the devices from the JAVA ap- 

15 piets pass from the device application portion 84 to the 
device server 92, and the instructions therefrom to the 
device interfacing software portion 64 in the ATM. De- 
vice operation messages take a reverse path. As these 
messages pass through the device server 92. monitor 

20 software 102 monitors them to minimize the risk of fraud 
or abuse. 

[0110] As indicated in Figure 21 , the documents from 
the foreign server 96 may be operative to display at the 
touch screen 30 a request for the customer to input their 

25 pin. The embedded JAVA script instructions would, as 
in the sample transaction previously discussed, include 
instructions that enable the keyboard 40 to accept the 
customer's PIN. As in the prior example, a transaction 
record 104 which includes a shared data object con- 

30 cerning this transaction would be opened by the device 
application software portion. As previously discussed, 
provisions may be made to prevent the passage of PIN 
data through the browser if desired. 
[0111] Figure 22 indicates the return of the device op- 

35 eration message and PIN data to the JAVA applet, which 
in turn transmits the data back to the foreign server 96 
through the wide area network 1 8 using the secure sock- 
et connection. From this point the transaction proceeds 
generally as previously described, except that the for- 

■»o eign server 96 sends the HTTP records, including HTML 
documents, and receives the messages from the docu- 
ment handling portion of the ATM. The foreign server 96 
includes the JAVA application software necessary to in- 
clude the embedded JAVA script in the documents that 

•*s are sent to the ATM to operate the devices 36 in the 
machine. 

[0112] As the foreign server 96 operates the machine, 
the monitor software 102 in the device server 92 is op- 
erative to monitor the messages in the manner previ- 

so ously discussed. Such monitoring would for example, 
operate to prevent the dispense of unduly large amounts 
of currency out of the machine. The monitoring software 
may also operate to restrict certain foreign institutions 
to a subset of the transaction machine devices or capa- 

55 bilities. This is done based on data stored in memory 
which limits the devices or activities that can be carried 
out from documents at certain addresses. This may be 
achieved for example through the use of code plug-ins 
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which implement a class of the transaction objects 
which limits the operations that can be performed. For 
example, the operations which enable connection to the 
foreign server may instantiate the objects which provide 
specified limited capabilities for messages received 
from the foreign server. This may for example limit the 
amount of money dispensed, prevent operation of a 
check acceptance device, limit the dispense to printed 
documents such as tickets, prevent operation of the 
cash dispenser or limit use of the machine in other ap- 
propriate ways. This may be done based on the ad- 
dresses or portions of addresses for documents. 
[0113] If the capabilities of the machine to the foreign 
customer are limited, the foreign customer may be pro- 
vided with a visual interface from the foreign bank based 
on the transactions the machine can perform and that 
the owner of the machine will allow. As a result the doc- 
uments accessed at the foreign bank server may be a 
variation of what the customer would be provided at a 
machine operated by the foreign bank. This could be 
based on documents specifically developed for operat- 
ing foreign machines, or could be a variant of the usual 
foreign bank interface with visual indications that certain 
transactions are not available. In some instances the in- 
terface may indicate that some transactions are availa- 
ble with an associated service charge. 
[0114] The ATM of the described embodiment may 
enhance security by limiting the addresses that the 
browser may access. This may be done by maintaining 
a list in the memory of the machine. This list may be 
maintained in HTTP record(s) (including documents) 
accessible through the home bank's intranet. The ma- 
chine may access the record periodically and update the 
memory data. This record may itself require a digital sig- 
nature corresponding to a signature in the terminal 
memory before the data will be loaded into terminal 
memory. This information may also include the instruc- 
tions and information for the ATM to verify that the mes- 
sages it receives by accessing documents on the for- 
eign server are genuine. This may include digital signa- 
tures which when transferred using public key or private 
key encryption techniques verify the messages as gen- 
uine. The machine checks to be sure the signature in 
the records accessed from the foreign server corre- 
sponds to the digital signature for that address stored in 
memory, and enables operation of transaction devices, 
such as the cash dispenser, only when such corre- 
spondence is present. Of course various approaches to 
verifying and encrypting messages may he used in var- 
ious embodiments. As used herein signatures or signed 
record encompass any indicia which is included in or is 
derivable from a record which is indicative that it is au- 
thorized. 

[0115] As can also be appreciated from the foregoing 
disclosure, the foreign server 96 may communicate to 
the user through the touch screen in a language that is 
different from that normally used by the customers of 
the institution that operates the computer system 14. As 



a result the HTML documents may display requests to 
dispense currency of a type or in an amount which is not 
included in the ATM. To accommodate this situation an 
applet is preferably included in the device application 

5 portion 84 to deal with requests for foreign currency. The 
foreign currency applet causes the ATM to send a mes- 
sage back to its home server for purposes of calculating 
a closest amount which may be provided to the custom- 
er in the available currency in the ATM which corre- 

10 sponds to what the customer requested. As will be ap- 
preciated, this applet will be operative to call the partic- 
ular function address within the home server 90 that is 
capable of providing this function. When the dispense 
is made the applet is also operative to indicate to server 

75 96 that the amount dispensed differs somewhat from the 
amount the customer requested. Of course in other em- 
bodiments, other approaches may be used. Alternative- 
ly an applet in the machine may generate visual displays 
that show equivalents in local currency when foreign 

20 currency amounts are displayed or processed. This may 
include presenting both amounts on visual displays pre- 
sented to a user. 

[0116] As represented in Figure 23. whell the foreign 
customer has completed their transactions as indicated 

25 through the touch screen 30. the foreign server 96 is 
operative to send the "go home" message back to the 
ATM. The receipt of this message is operative in the 
manner previously described to cause the device appli- 
cation portion 84 to operate responsive to the embed- 

30 ded JAVA script instructions to configure the HTML doc- 
ument handling portion to cause the browser 76 to re- 
establish communication with the home server 90. or 
other designated document address. 
[0117] As indicated in Figure 24 the applet in the de- 

35 vice application portion 84 which processes the "go 
home" message is preferably operative to reconnect to 
the home server 90 as well as to send the transaction 
record information in record 104. This transaction record 
information which is preferably packaged in a data ob- 

40 ject. includes the customer name, the foreign institution 
name, digital identifier, amount information concerning 
amounts dispensed, transferred or deposited, and all 
other pertinent transaction data. The transaction data is 
used by applets in performing transaction steps in which 

■*s any portion of the data is required. At the completion of 
the customer's activity at the machine an applet pro- 
vides a transaction data message which includes at 
least a portion of the collected data. This data is com- 
municated from server 90 through the CGI 106 to the 

50 home bank's back office 94. This information is stored 
in the back office for later use for purposes of settlement 
with the foreign bank operating the foreign server 96. 
Alternatively or in addition, transaction data may be re- 
corded in the terminal in memory as well as in hard copy 

55 on a journal printer. Transaction data may be stored for 
downloading in a batch or by passing objects including 
data from many transactions. Batch data may be com- 
municated at times and to addresses as may be stored 
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in memory in the terminal configuration data. 
[0118] An advantage of some embodiments of the in- 
vention is that transaction data may be delivered to ad- 
dresses in a local area network or in a wide area network 
such as the Internet. This facilitates conducting wide va- 
rieties of transactions and enables directing messages 
related to tracking use (such as for electronic purse type 
smart cards) or for settlement of various transaction 
types to a selected system address. 
[0119] It will be appreciated that the described em- 
bodiment of the automated banking machine and sys- 
tem can provide an advantage that when the machine 
is connected to a wide area network such as the Internet , 
customers are able to carry out their banking transac- 
tions virtually anywhere in the world. Further despite the 
broad capabilities of the system, because the machine 
may be monitored locally, both in terms of connection 
and activity, the risk of fraud is minimized. 
[0120] Embodiments of the invention may include a 
further feature to facilitate access to documents in the 
network to which the machine is connected. This feature 
is operative to determine if an HTTP record such as an 
HTML document or other item is accessible at an ad- 
dress for downloading before the computer will attempt 
to access the record. This avoids transaction time outs 
that might otherwise occur as a result of inability to ac- 
cess a record due to the server through which the record 
is normally accessed being down. Other embodiments 
may consider both the size of the record and the transfer 
rate and determine that a transfer speed for the record 
is not sufficiently rapid, so that an alternative record 
should be transferred. 

[0121] In one embodiment this feature is achieved 
through use of a separate program or applet which 
checks to see if a server that the computer will subse- 
quently want to access is alive. The applet operates re- 
sponsive to receiving an address or portion thereof, to 
which a connection will be made. The applet operates 
to make a socket connection to the address and loads 
a small but sufficient amount of the record or otherwise 
operates to determine that the server through which the 
record must be accessed is alive. In response to the ap- 
plet verifying the operation of the remote server or oth- 
erwise determining that conditions indicative that the 
record may be accessed or loaded, the computer then 
operates so that the browser or similar software compo- 
nent is enabled to navigate to the address at the appro- 
priate time in the transaction sequence. If the applet is 
unable to detect that the remote server is alive, or de- 
termines that it does not appear the record may be suc- 
cessfully accessed or loaded, steps may be taken to ac- 
cess alternative addresses or to discontinue the trans- 
action. Alternative addresses to access may be based 
on data stored in the memory of the terminal or may be 
obtained by accessing documents either locally or re- 
motely which include data from which alternative ad- 
dresses may be obtained or derived. Alternative ad- 
dresses are similarly checked to make a determination 



that the records can be accessed before attempts are 
made to access the alternative records. This approach 
avoids delays in carrying out transactions. 
[0122] Alternative embodiments may employ other 

5 approaches to determine if desired HTTP records such 
as HTML documents may be successfully accessed 
and/or downloaded adequately before the browser pro- 
viding the customer interface attempts to access the 
document. Such embodiments may consider in deter- 

10 mining whether the document can be successfully ac- 
cessed, the transfer speed or other conditions related 
to system operation or document content. For example, 
the applet which tests to determine that the HTTP record 
can be accessed, or a further applet, may determine the 

15 transfer rate at which the record can be transferred to 
the computer. The rate at which the data can be trans- 
ferred may be compared to data stored in memory, and 
if the rate is slower than the data representative of the 
desired stored rate an alternative record is accessed. 

2o This may be for example an HTML document stored lo- 
cally in the machine. Other embodiments may include 
programs which consider the size of the HTTP record 
and the transfer rate in determining a transfer speed. 
Such programs then determine if the record can be 

25 transferred fast enough to suit the parameters estab- 
lished in the configuration in memory, and if not, alter- 
native addresses are accessed. Such alternative 
records may be similarly tested for transf erspeed before 
being transferred. 

30 [0123] Programs may also consider other factors in 
deciding to access a particular address, such factors 
may include for example day and time information, or 
information from sensors such as sensors in a floor in- 
dicating that other persons are waiting to use the ma- 
ss chine. In this way access to documents that have exten- 
sive outputs which may tend to prolong transactions can 
be avoided even when records can be loaded at an ad- 
equate speed. 

[0124] While the described embodiment of the auto- 

40 mated banking machine and system of the present in- 
vention is shown with regard to a particular type of ma- 
chine that is made specifically for connectivity to local 
or wide area networks, conventional automated banking 
machines may also be adapted to include such capabil- 

45 ity. Specifically the HTML document handling portion 
and device application portions may be included with 
other conventional software which operates within an 
automated banking machine. This enables such ATMs 
to operate either in the conventional proprietary network 

so or as part of a wide area network. In addition, automated 
banking machines may be configured to operate their 
devices through the device interfacing software portion 
described herein or through a different software inter- 
face when operating in a conventional network. Such 

55 machines may switch to requiring device messages to 
be passed through a device server when operating un- 
der the control of a server within the wide area network 
to maintain security within the system. In this way a sin- 
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gle ATM could operate in proprietary networks in the 
manner of current ATMs as well as in the network con- 
figuration of the system described herein. 
[0125] Alternative embodiments of the invention op- 
erate to communicate transaction messages used in a 
proprietary ATM network. This may be accomplished by 
using a CGI in connection with either the HTML docu- 
ment handling portion of the ATM or the HTTP home 
server or other server. The CGI operates in connection 
with a message conversion program and database to 
cull the necessary data from the HTML documents and 
response messages and generate the defined transac- 
tion request messages appropriate for the proprietary 
transaction network. Likewise, the message conversion 
program and CGI operate to receive function command 
messages from the proprietary network and convert 
them and generate appropriate HTML documents and/ 
or TCP/IP messages for use by the ATM. Because these 
proprietary network formats are defined and the data 
necessary to produce and interpret the messages are 
known, the use of the ATM 1 2 directly in a conventional 
proprietary ATM network is achieved. 
[0126] Conventional ATM transaction messages are 
defined layout messages that do not include HTML doc- 
uments on HTTP messages. An example of known con- 
ventional messages used to operate ATMs are Diebold 
91 X messages. Such messages generally involve 
transmission of a request message from an ATM in a 
defined layout including customer input data (account/ 
pin) and an indication of the type and amount of trans- 
action requested. The request message is received by 
an ATM host computer which sends back a response 
message with a defined layout which includes an indi- 
cation whether the transaction is authorized. The ATM 
then returns another message to the host computer in- 
dicating whether the machine was able to carry out the 
transaction. The messages used in such conventional 
proprietary networks generally occupy relatively little 
band width. 

[0127] In connecting an ATM according to an embod- 
iment of the invention to such a network, a server is pro- 
vided. The server is in operative connection with a mem- 
ory which includes a relational database which holds the 
message conversion and document creation data. In 
one configuration, the server is connected to the docu- 
ment handling portion through a network, or may reside 
on the computer of the ATM. The server produces the 
documents which the browser accesses and which in- 
clude the transaction device instructions. The server (or 
a connected server) communicates the conventional 
messages with the host. One server may provide an in- 
terface for several ATMs connected to it in a LAN, or 
alternatively, each ATM may have its own server oper- 
ating therein. 

[0128] The ability of ATM 1 2 to communicate in a pro- 
prietary network also enables operation of the ATM in a 
manner in which the interface is generated by a user's 
home institution in the manner previously described, but 



in which transactions are authorized through messages 
directed through a proprietary ATM network. This 
achieves the security of using the proprietary network 
while providing the customer with the advantages of the 
5 familiar home bank interface and/or "personal home 
page" interface. 

[0129] In such a configuration the ATM transaction 
function devices may be operated in a conventional 
manner in response to conventional ATM transaction 

10 messages such as Diebold 91 X messages, in the pro- 
prietary network. The customer output devices, such as 
the screen (and speakers if provided) communicate 
through a browser connected to a local or wide area net- 
work. The browser accesses documents to prompt a 

is customer through operation of a transaction, but the 
documents do not include instructions which cause op- 
eration of devices such as the cash dispenser. 
[01 30] In one configuration the browser may be oper- 
ated by the computer in response to the status of devic- 

20 es in the machine, as the devices are operated in re- 
sponse to conventional ATM messages. In this manner 
the browser may be navigated to selected addresses, 
including addresses which are associated with the cus- 
tomer based on customer input data. However, as the 

2S documents received by the browser will not operate the 
transaction function devices, there is less need for se- 
curity measures in accessing documents. As a result, 
the customer may still operate the machine in response 
to a familiar and unique interface, and marketing infor- 

30 mation such as advertising or other material may be pre- 
sented in the transaction sequence. 
[0131] In other embodiments machines may perform 
some device functions based on conventional messag- 
es, while others may be performed in response to in- 

35 structions in HTML documents or other HTTP messag- 
es. For example HTML documents may provide consid- 
erable data for use by printers or other output devices. 
Some embodiments may access documents with in- 
structions, but may ignore some and act in response to 

■to others. The approach may be selected by the systems 
operator by configuring the software based on their re- 
quirements. 

[0132] A further advantage of the system configura- 
tion of one preferred embodiment is that it has enhanced 

■ts flexibility for communicating messages associated with 
the ATM. The device manager 68 preferably generates 
status messages associated with the status of devices 
36. These status messages may commonly represent 
information about conditions which exist at the devices. 

so Such messages may indicate that supplies of paper for 
printers or currency, are low or are depleted. Other mes- 
sages may indicate that devices are not functioning 
properly. Often such messages indicate that the ATM 
requires servicing. All such types of messages are re- 

55 ferred to herein interchangeably as status or fault mes- 
sages. 

[0133] The device interfacing software portion 64 
communicates through the intranet 16 using TCP/IP 
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messages. While the messages associated with trans- 
actions previously described are directed to the device 
server 92, the software portion 64 may include a server 
and be configured to address fault and status messages 
to other addresses in the intranet or the Internet. For 
example, such fau It or status messages may be directed 
to a software application which delivers messages to a 
service provider. Further, fault messages may be selec- 
tively directed based on the nature of the fault indicated. 
For example, fault messages indicative of a need to re- 
plenish currency or supplies may be directed to an ad- 
dress in the intranet associated with an entity who has 
responsibility for replenishing supplies. Alternatively, 
fault messages which indicate a need for other types of 
servicing may be directed to an address associated with 
an entity who can provide the type of servicing required. 
[0134] Alternatively, the selective dispatching of fault 
messages to addresses in the intranet 16 may be ac- 
complished by appropriately configuring device server 
92. In addition, either software portion 64 or device serv- 
er 92 may direct fault messages from the ATMs to a fault 
handling system such as to a computer operating Event 
Management System™ software available from Die- 
bold. Incorporated. Such software is operative to re- 
solve the nature of the fault condition and to notify ap- 
propriate personnel of the corrective action to be taken. 
[0135] The ATM 12 may further include a software 
function to assist in diagnosing problems and providing 
remedial service. As graphically represented in Figure 
2. alternative embodiments of the ATM 1 2 may include 
a mini-HTTP server 109 which is in communication with 
the device interfacing software portion 64. Server 109 
is configured to receive device status messages and to 
produce HTTP records including HTML documents in 
response thereto, which provide data representative of 
device status to a diagnostic device 1 1 0 such as a hand 
held computer terminal. Server 109 includes a CGI for 
interfacing with the device software so that a technician 
may access the information in the records accessible at 
the HTTP addresses related to status messages and in- 
put test and corrective instructions through diagnostic 
device 110. The HTTP records and/or HTML documents 
generated by server 1 09 may preferably include graphic 
and audio instructions indicative of conditions such as 
problems, as well as corrective action data and repair 
instructions. 

[0136] In alternative versions of the invention the 
functions of the mini-HTTP server 1 09 may reside in de- 
vice server 92. This may be particularly appropriate 
where the function of the device server resides on the 
computer in the ATM. Regardless of where the function 
resides the use of the visual and audio components of 
HTML documents associated with maintenance and di- 
agnostic messages facilitates servicing of the ATM. 
[0137] These records delivered through the mini-HT- 
TP server include instructions that correspond to the 
status or fault conditions. Such records or documents 
may be accessed locally as previously discussed, or re- 



motely. A technician using a hand held computer which 
includes a browser or other software operative to access 
the HTTP records may access the documents locally for 
purposes of maintenance, diagnosis and servicing. In 
s some situations the customer interface and browser as- 
sociated therewith may be used to access the mini-HT- 
TP server, or a separate browser, display and input de- 
vices on the machine and intended for use servicing ac- 
tivity may be used. Alternatively, the fault and status 
10 messages may be monitored from terminals at locations 
anywhere that are connected in the network. The mini- 
HTTP server handling status and fault messages may 
also be configured to send an email or similar message 
to a selected address whenever a particular condition 
is or group of conditions exist. 

[01 38] A further advantage of this feature is that HTTP 
messages may also be sent to the mini-HTTP server to 
attempt to correct problems. Such messages may in- 
clude running diagnostic tests and receiving results. It 
20 may also include operating devices to test or attempt to 
clear jams and other malfunctions. This can often be 
done from remote locations. Of course, when there is a 
significant risk of unauthorized access to the server han- 
dling default or device messages, appropriate security 
25 measures should be taken. 

[0139] The HTTP records which indicate the status of 
the transaction function devices may have different 
forms depending on the software configuration and the 
needs of the system operator. In some embodiments the 
30 device status information for one or more devices may 
be represented by indicia contained within a data object. 
The data object may be transferred to other connected 
computers to provide the status data. The transfer of the 
data object may be accomplished by remote method in- 
35 vocation (RMI) for example. The data in the transferred 
data object may then be used to generate message and/ 
or outputs desired by the system operator. This tech- 
nique may be particularly useful when the operator wish- 
es to connect the machine to an existing monitoring sys- 
40 tern and indicia included in the data object can be used 
to generate outputs or messages indicative of device 
status that can be processed by the existing system. 
Plug-ins may further be used to achieve communication 
between existing monitoring systems and transaction 
45 machines which have different types of status condi- 
tions or different types of message formats. This in- 
cludes machines which have different types of transac- 
tion function devices and capabilities. 
[0140] The technique of transferring a data object 
50 may also be used to conduct testing or modification of 
transaction function devices. For example, indicia in the 
data object may be modified by a servicer and the object 
passed back to the machine. The software in the ma- 
chine may cause the transaction function devices to op- 
55 erate or change conditions or programming in response 
to the modified data object. This may include for exam- 
ple clearing a fault indication or causing a device to op- 
erate to clear a jam or to conduct a test. The results of 
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such activity may be reflected in modified indicia in the 
data object which may then be transferred to the com- 
puter in the diagnostic terminal. Of course, the ap- 
proaches discussed herein are exemplary and other ap- 
proaches will become apparent to those skilled in the 
art from the description herein. 
[01 41 ] Figure 25 shows a schematic view of a network 
configuration for an alternative embodiment of the au- 
tomated banking machine. 

[0142] The embodiment shown in Figure 25 includes 
an automated banking machine specifically adapted for 
operating in connection with conventional automated 
banking machine systems such as systems which op- 
erate using Diebold 91 X ATM message formats or other 
non-HTTP conventional format. A host computer 120 is 
a conventional ATM host which communicates using 
such messages. The host communicates with an inter- 
face server schematically indicated 122. Interface serv- 
er 1 22 operates in the manner previously discussed and 
is in operative connection with a memory that includes 
the information necessary to convert HTTP messages 
that pertain to a transaction request to a 91 X request 
message or other conventional message, which can be 
handled by host computer 120. Likewise interface serv- 
er 122 and the instructions and data stored in memory 
are operative to convert a conventional 91 X command 
message or other conventional command message 
from the host 120 into HTTP messages which can be 
used by the automated banking machine to carry out the 
command. Similarly interface server 122 is operative to 
receive the HTTP messages which correspond to the 
response of the automated banking machine to the com- 
mands and to produce a 91 X response message or oth- 
er conventional response message to the host. In ac- 
complishing these functions the interface server com- 
municates with a interface client 124 which in the pre- 
ferred embodiment is a COMM plug in which operates 
on the banking machine terminal under a Windows NT® 
operating environment. Interface server 122 also in- 
cludes a command/status gateway 126. The command/ 
status gateway is operative to receive command and 
status messages from the software portions handling 
the functional devices within the machine. The messag- 
es concerning the devices are used in producing trans- 
action messages to send back to host 120. In addition, 
the command status gateway portion also produces sta- 
tus messages indicative of the status of devices which 
may also be communicated to the host. 
[0143] The interface server 122, command status 
gateway portion 1 26 and interface client 1 24 may reside 
in software on the automated banking machine terminal. 
In this configuration the terminal appears to the host 
computer to be a conventional machine. Alternatively in- 
terface server 122 and command status gateway por- 
tion 126 may reside on a separate server, while the in- 
terface client portion 124 may reside on the terminal. 
This enables the interface server 122 to handle a 
number of automated banking machines by connecting 



the machines to the interface server through a network. 
[0144] The alternative configuration of the automated 
banking machine system shown in Figure 25 is particu- 
larly adapted for use in connection with existing ATM 

5 system. The machine includes an HTML document han- 
dling portion 1 28 which includes a browser which oper- 
ates in the manner of the embodiments previously de- 
scribed. The HTML document handling portion is alter- 
natively referred to as a browser herein for purposes of 

10 simplicity. The HTML document handling portion oper- 
ates in connection with a network 1 30 to access HTTP 
records in the form of HTML documents through servers 
1 32. 1 34 and 1 36. For purposes of this example server 
132 will be considered the server of the home bank 

is which operates the automated banking machine. The 
browser portion 128 is enabled to access documents of 
its home bank for purposes of obtaining content and in- 
structions for purposes of outputting information to cus- 
tomers as well as for operating devices on the machine. 

20 Servers 1 34 and 1 36 are representative of other servers 
which the automated banking machine may be instruct- 
ed to access for purposes of downloading documents 
which include information or instructions. Often such 
documents from non-home bank servers will include in- 

25 formation which is to be presented to customers such 
as advertising, promotional material, stock quotations or 
other types of information. It should be understood that 
the servers 134 and 136 may be directly connected to 
network 130 or may be accessed through other net- 

30 works and servers. In some embodiments such servers 
may be accessed through the internet for purposes of 
providing documents to the automated banking ma- 
chine. 

[0145] Document handling portion 128 includes a ter- 
35 minal theater software portion schematically indicated 
138. Terminal theater portion 138 is schematically 
shown in greater detail in Figure 26. Terminal theater 
portion 138 includes a back stage frame 140 and a 
theater frame 142. The back stage frame 140 although 
40 it resides in the browser, is not visible on the screen of 
the automated banking machine. The theater frame 1 42 
is a visible frame and controls what is shown to the cus- 
tomer. 

[0146] As schematically represented in Figure 25 the 
45 HTML document handling portion also includes a termi- 
nal director portion 1 44. The terminal director portion in- 
cludes directors which are related instances of applets 
which are used in carrying out particular types of trans- 
actions. The terminal directors generally correspond to 
50 the operation of the JAVA applets in the previously de- 
scribed embodiment. 

[0147] The automated banking machine of the alter- 
native embodiment further includes a transaction serv- 
ices application (TSA) schematically indicated 146. The 
55 transaction services application provides security, ter- 
minal condition, terminal authorization and key manage- 
ment services within the automated banking machine. 
The transaction services application includes a function 



